Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / rec_110.arc / RECSYSOP.DOC < prev next >

Wrap

Text File | 1991-09-10 | 50KB | 1,157 lines

Remote Echo Control (REC) Version 1.10 Live Public Release For free distribution to whoever needs it Sysop Documentation Copyrighted (c) 1990, 1991 by Daniel S. Fitch All Rights Reserved LICENSING AGREEMENT AND DISCLAIMER Remote Echo Control (REC) and its accompanying utilities are copyrighted by Daniel S. Fitch, and all rights are reserved. They are not to be decompiled, altered, or re-engineered in any way. This includes any patches to the load modules, and removing the copyright notice that is displayed when the programs are executed. Changing the archive format is permitted. As this software is copyrighted, I expect that no one will try to take credit for the work that I have done. The software is to be distributed free of charge, with the exception of a nominal charge for postage or disk media. Charges incurred by users of a Pay BBS are not included in this restriction, unless the charge is tied explicitly to REC. You use the software at your own risk. I will not be responsible for any damages resulting from the use of REC, including but not limited to software, hardware, outages, or monetary. I have taken all reasonable steps to properly test this software, and will take all reasonable steps to correcting any problems discovered. If you do not agree to these restrictions, then do NOT use this software. Use of this software indicates that you agree to these terms. REGISTRATION You are expected and required to register the software. This way I know how many copies are in use, and whether I should continue to maintain it. Registered users will get first notice on updates, and ONLY registered users will be allowed to be beta testers. There is no charge for registration. REC and its accompanying utilities are not crippleware. There is no change in operation of the software by registering the software. Registration takes only a simple net-mail message to Dan Fitch on 1:104/435@FidoNet or 200:5000/211@MetroNet. Include your name, date of software installation, where you got the software, your return net-mail address, and the city/state where your system resides. I will keep this information confidential, and use it only for purposes of maintaining REC. TROUBLE REPORTS No matter how much testing is done, any software is bound to have glitches or bugs present. This includes the documentation. Please feel free to report any problems via the REC_SYSOP support echo, or via private net-mail. It is available via the MetroNet distribution system, and can be received in FidoNet via a gateway link. You may be asked to send your configuration and echo control files to the author at the name and address listed above for registration. Please be sure to supply the include the following information: Complete hardware description Compete software description Which release of REC you are running Any program terminations messages Copy of relevant portion of the log file Complete copy of your configuration file A short narrative of the problem Anything else you think might be needed A voice number to reach you if necessary INTRODUCTION Enough of the legal matters and on to the program! Remote Echo Control (REC for short) is simply a zone-aware, point-aware program written for echo hubs that allows your echo nodes to remotely control which echos they receive from your system. This is done with no manual intervention on your part. Installation is quick, configuration is simple, and execution is fast, and logging is complete. I did say that this program is zone-aware, and with good reason. While there are several similar programs already available, I have not found one that will both recognize zones and work in multiple zones at the same time. Such zone support is required when you are an echo hub in a zone other than your primary zone. It is also highly recommended if you are an echo hub and your system has addresses in multiple zones. It is fully compatible with the forms of point addressing used by most echo mail processors. You can use the private net, point reference, or a fully qualified address. If you are not involved with point systems, don't worry about this. If you are then please read the section on point systems. REC is also Zmail compatible. In fact, I wrote REC to work with Zmail specifically but be flexible enough to not be killed by minor changes to Zmail or by use with other mail processors. By default, an echo node can only request echos with a feed in the same zone the the requesting echo node. This is fine for the majority of those using this software, but it presents a major hassle for gateway systems. Therefore, CrossZone configuration statements can be used to allow certain echos to cross certain zone boundries. REC will work just fine if you are an echo hub and have addresses in only 1 zone. However, I strongly encourage that you do use that zone in all your addressing in REC. Network addresses will default to zones or net not specified, but you will have less to think about if you do not use the defaulting procedure. DEFINITION OF TERMS Just so everyone is using the same terminology, I will briefly describe the terms I will be using in this documentation. This is not intended as a short course, but rather as a translation. ECHO - The actual message area that is passed from system to system. ECHO HUB - The system that sends echo mail to your system for you to distribute. ECHO NODE - The node receiving echo mail from your system. LOCKOUT - Blocking an echo from receiving mail on an certain echo. This could be needed for several reasons, including Network Policy, local Net policy, or echo moderator decree. CROSSZONE - Allowing certain echo nodes to access echos from zones other than there own. This is not very common, and is subject to a variety of policies in all networks involved. You have the capability, and the responsibility. USER INSTRUCTIONS Included in the distribution archive is an file called RECUSER.DOC, and it contains the instructions for your echo nodes on how to use REC. I suggest that you read it right now. It will be easier for you to setup and understand how REC works if you now what your echos nodes will be trying to do, and how they will go about doing it. INSTALLATION While you can place REC in any directory on your system that you wish, I suggest that you place it in its own directory. This will make program updates easier and keep your hard disk somewhat more organized. The first step is to un-archive the distribution file into the directory that you wish to use. The original distribution file contains the following files: REC.EXE - The main program REC.CFG - A sample configuration file RECSYSOP.DOC - Sysop documentation RECUSER.DOC - User documentation HISTORY.DOC - Revision History NOTIFY.HDR - A sample notify message header REPLY.HDR - A sample reply message header The distribution file also contains a few little utility programs that you may find useful. They were written for the sysop of an echo hub, and are part of the REC package. Consider them a bonus. These utility programs are listed below and explained later in this documentation: AREALIST.EXE - Alphabetical listing of echos AREARPT.EXE - Echo Distribution Report ECHOSOUT.EXE - Outbound echo mail tracker READMSG.EXE - Formatted Display of .MSG file To put REC in your batch files may require a bit of re- working of your inbound mail processing. Two rules must be followed exactly: 1) always process net-mail before ANY echo mail, and 2) always run REC before you import the mail into your message base. A typical scenario would be similar to this sequence of events. First, you process all net-mail packets and create .MSG files, which are placed in your mail directory. Second, you run REC to process any messages for REC. Third you run your net-mail importer to import any remaining .MSG files into your message base. Lastly, if any .MSG files remain in the mail directory, run your net-mail bundler to make packets out of the .MSG files. This scenario will be to be done whether you are processing non-compressed or compressed mail. This will ensure that all echo mail changes are complete before you processes any new echo mail. REC is now on your BBS, and ready to be configured. Coincidentally, Configuration is the next topic to be discussed. CONFIGURATION The configuration file for REC is a standard ASCII file that you can edit with any ASCII or Text editor. The example is broken down into 6 sections, but the actual order you use is up to you. Certain entries are required, other entries must occur at least once, and some entries are optional. The entire configuration will be verified at the start of each run of REC, which only takes a second or two. The entries are case- insensitive, and the keywords must be followed by a single space. If an entry can have more than one field after it, these fields must be separated with a single comma. With the exception of SystemName and SysopName, any spaces in the field must be typed as an underscore ("_"). The program will replace them with spaces when the configuration file is processed. Each of the entries are described below in alphabetical order. They appear in "logical" groups in the sample REC.CFG file. For examples, please refer to the sample configuration file found in the distribution file REC.CFG. Address (MINIMUM 1)- This is a list of all the addresses that your system is known as. This list should include every address that your system uses to pass echo mail in areas that you want to control with REC. If you have addresses that you do NOT use for echo mail traffic, do NOT list them here. At best they will do nothing, at worst you will get wrong addresses on your outbound mail. You may specify up to 10 Addresses, and the first address must be your primary address. The should be in the same order as your front-end mailer software. EchoControlFile (REQUIRED) - This is the complete path and name of the file that controls how the echos are distributed. Only one file can be specified and must be in the format shown below. All fields are separate by at least one space. All fields are required except the receiving addresses. {location} {echo tag} {main feed} [receiving addresses] Location - Can be any value desired, such as a directory name, board number, or Pass Through indicator. No spaces are allowed in this field. Echo Tag - The name of the echo area. Main Feed - Your echo hub's address for that echo Receiving Addresses (optional) - The addresses that your send this echo to. This should be compatible with nearly all echo mail processors. If it is not compatible with your mail processor, get in touch with me so I accommodate your needs. EchoHub - This is the definition of your echo hubs, which are your primary echo feeds. This statement is not really required, but omitting it does take away some of the more useful features of REC. An entry is needed for any echo hub which you want to use automatic forwarding, which will be described in the REC Processing Section. The format is shown and described below. EchoHub {address},{send to},{subject}[,type} Address - The network address of your echo hub. Send To - The name that you want to address the message to. Subject - The text that you want to see on the message subject line. Type (option) - Two possible values can be placed here: "REC" or "Areafix". If the field is omitted or has any other value, it will be ignored. This field is used only with Automatic Forwarding, and is described in the REC Processing Section. The default value will have messages addressed for a human being to read. EchoNode (MINIMUM 1)- This is the definition of each of your echo nodes that you want to use REC with. You can have nodes listed in your Echo Control File that are not listed as an Echo Node, but only nodes listed as Echo Nodes will be allowed to use REC. The only optional fields are the 3 sysop names. The format is described below: EchoNode {address},{echo hub},{password},{security}[,sysop name 1][,sysop name 2][,sysop name 3] Address - The net address of the echo node being defined. Echo Hub (Optional) - The net address of the echo hub that any forwarding echo requests should be sent to. This address must be defined with an Echo Hub entry. Password - This the password that your echo node must use to get access to REC processing. Security - This is the numeric security level (0 - 32767) that the echo node has. The echo node will only be able to request echos with an security level equal to or below its own security level. Sysop Name 1-3 - You have the option of restricting REC access by name. The password checking is still active. If at least 1 name is specified, then the sender of the REC message must be listed here for REC to accept the message. If no names are specified, then the message will be accepted by REC no matter who the sender is. These fields are also used by some other parts of REC, so I strongly encourage to specify at least one name for each echo node. MailDirectory - This is the directory that you will place net mail messages. REC requires that incoming net-mail and out-going net-mail be placed in the same directory. These messages must be in MSG format per Fidonet Technical Standard #001 (FTS-001). SystemName - This is the name of your system, and will be placed on generated messages to your echo nodes and your own echo hubs. SysopName - This is your name, and will be placed on generated messages to your echo nodes and your own echo hubs. Below are all of the optional statements that can be used: AccessName - This is the name that you want your echo nodes to use when they sent a message to REC. If not specified, this entry will default to "Remote Control". CrossZone - This command will permit echos to cross the zone boundry as long as the requesting echo node has at least the minimum security stated in this statement. The two flavor parts are optional and is discussed in the CrossZone section. The maximum number of statements is determined by how much RAM you have available. The format is shown below: CrossZone {from zone},{to zone},{security}[,[node flavor,] [zone flavor]] Lockout - This allows you to specifically deny access to an echo by a particular node, with a maximum of 50. No validity checking is perform on either the echo tag or the address. The maximum number of statements is determined by how much RAM you have available.The format is shown below: Lockout {echo tag},{address} NotifyHeader - This does the same thing as ReplyHeader, except that it is used for any notification messages created by using the "/N" command line parm. PassThrough - This allows you to specify the board that will designate a pass-through echo. The default value is "P". ReplyHeader - This allows you to specify a "canned message" to be put on all replies created by REC. It only needs to be in straight ASCII text format, with NO ANSI characters. Secure - This allows you to specify a security level on individual echos. The security level of an echo will default to 0 unless it is specified here. Valid security levels range from 0 to 32767. No checking is performed to ensure the echo tag exists on the echo control file. The maximum number of statements is determined by how much RAM you have available. The format is shown below: Secure {echo tag},{security level} SortBoard - This will make REC sort the echo control file by echo board number. It has the same sectional sorting capability as SortName. If two echo areas have the same board, then REC will automatically use a secondary sort key of echo tag. SortName - This will make REC sort the echo control file by echo tag. All sorting is done between comment lines. In other words, if you use comments to break you echo control file in a section for non-echo areas, general echos, and private echos, all sorting will occur within the individual sections. The sections will NOT be merged. StatusReport - This statment will cause REC to create and send to the Sysop a net-mail message. This message will detail out the status of you echo control file and well as your echo nodes and echo hubs. This report is described in detail in a later section. ADDRESS DEFAULTING The addresses that you specify will default in 3 different ways. This defaulting allows REC to determine address information if a piece is missing. I strongly urge you to specify the complete zone, net, and node for all addresses in the configuration file, and on all echo feeds in the echo area control file. The first Address statement you specify will default using the address of 0:0/-1. Validation checks will be performed to make sure that the address does not have a negative number for any field. Additional Address statements, Echo Hubs, Echo Nodes, Security, and Lockouts will all default using the first Address statement. You can see why it is important to have your primary address listed first. If you do not follow this rule, your mail will end up going to the wrong zones. Addresses in the echo control file default using 2 rules. The Main Feed of the echo defaults to the first Address statement in the Configuration file. The first Receiving Address will default to the Main Feed, and all other Receiving Addresses will default to the previous address listed. Please examine the example below for an illustration, and assume that the first Address statement in the configuration file is for 1:104/435: P SYSOP 1:104/1 200 303/202 204 205 3:100/1 110/50 The main feed will be 1:104/1. The complete receiving address will be 1:104/200, 1:303/202, 1:303/204, 1:303/205, 3:100/1, and 3:110/50. The simply the echo control file, REC will sort the receiving address in ascending order after processing, and write them back out in the "short form" shown above. Please note that since the complete address (including zone) was specified for the main feed, no defaulting was needed from the first Address statement. This is the safest way to proceed, and I highly recommend it. REC PROCESSING Processing occurs is several steps, and is build on the assumption that only one REC message will be processed per run. This is NOT a limitation, but an observation from my own system. If you process net- mail immediately after receiving it, you are not very likely to process more than 1 message (unless the echo node sent more than one message at a time). If you save up net-mail until a speicific time and than process them all at once, you will be more likely to processed several REC messages at one time. REC will process the configuration file and terminate if there are any errors. If there are any .MSG files to process, it will load the echo control file in to dynamic memory and process the .MSG files. The echo control file will also be loaded if batch mode is being used. All batch commands will be processed before any .MSG files are processed. REC will scan the specified message directory and find all .MSG file regardless of how the may be numbered. This is done to allow processing with Gateway Systems, which are the main exception to the observation shown above. After all processing is completed, all replies will be created. Then any file sorting (if any desired) will be done, and lastly the echo control file will be written out to disk. REC does not set any ERRORLEVEL's when it exits. If any are needed please let me know, and I will get them added. So far I have not seen or heard of any need for them. I may be wrong about this, so let me know if I am. AUTOMATIC FORWARDING I have mentioned Automatic Forwarding a few times, so now I will explain this neat little feature. You don't have to be an echo hub for long before one of your echo nodes asks for an echo that you are not receiving from your own echo feed. This feature will allow you automatically pass on a request to your own echo feed to start the echo. All that you have to do is specify an Echo Hub address on the Echo Node statement for each system that you want to use automatic forwarding. The address on the Echo Node statement much match the address of one of the Echo Hub statements. When an echo node requests an echo that is not found in the echo control file, the list of Echo Hubs is searched for a match on the echo hub address found on the echo node statement. If a match is found, a message is sent to the echo hub requesting that the echo be activated. The fact that the echo request was forwarded is noted on the reply message to the echo node and the log file. If a matching address is not found or an echo hub address is not specified on the echo node statement, an appropriate message is noted in the reply and on the Log File. This Automatic message can be sent to either a human or another automatic echo control system, and this is controlled by the Type field entered on the Echo Hub. At this point, REC can send messages to another REC (of course) or Areafix. There is only 1 difference between a message sent to a human or an automated system. A message to a human will have a short blurb at the beginning of the message asking to have the listed echos activated. Both types of messages will have a tear line ("--- ") followed by a short line informing the recipient that the message was created automatically by REC. The receiving address, receiving name, and subject line are all populated from the Echo Hub entry. To have a message to an AreaFix program, put "Areafix" (of whatever your echo feed is using) as the Echo Hub's send-to field and the password on the subject field. Remember you have to specify the class as either AreaFix or REC to either of those programs. It can't really be much easier. CROSS-ZONE ECHOS Allowing echos to cross zones was added for those gateway systems that do this regulary. There are policy rules and guidelines that must be adhered to when echos start crossing zones, and I have no intention of addressing them here. REC will assume that you know what you are doing if you employ this feature. The Cross Zone statement was described in the configuration section. Here are a few tips for easy use of the Cross Zone feature. First off, don't use it unless you need to use it. Beyond that, set the security for crossing zones above that of what you normally assign to echo nodes that do NOT cross zones. If you have any echos that should not cross zones, set their security higher than any of the Cross Zone statements. A word about Cross Zone and Automatic Forwarding: An echo node cannot have forwarding for multiple echo hubs. If you have a system in a zone that is getting echos from more than one zone, you will have to either disable automatic forwarding for that echo node (by not specifying an echo hub address on the Echo Node statement), or allowing automatic forwarding for only one of those zones. I realize that this could cause some problems for any gateways that cross several zones. If it does, please let me know and we can discuss a better solution. When echos cross-zone using this feature you can force Zmail flavors on either the echo node, or the echo feed. This is mostly used when running a gateway system. The first flavor code will be put on the echo node requesting the echo. The second flavor code will be put on the echo area's feed. You can use either, both, or neither. Please look at the examples shown below: CrossZone 8,1,3000 CrossZone 8,1,3000,H CrossZone 8,1,3000,,* CrossZone 8,1,3000,H,* The first example will allow an echo node in Zone 8 to access an echo from Zone 1, providing that the echo node has at least a security of 3000, and the echo has a security of less than or equal the echo node security. The second example does the same as the first, but will force the "H" flavor code (for "Hold") on to the echo node. The third example does the same as the first, but will force the echo area feed to have "*" flavor code, which will have Zmail leave these messages as *.MSG files. Do notice that there are two commas between the security and the Feed Flavor code. That is not a typo, but a requirement. The fourth example will do all of the above with just one statement. For more information on Zmail Flavors, see the next section. ZMAIL FLAVORS Zmail Mail Processor (Copyrighted by ZZYZX) allows special processing of the outbound flavors for your echo mail. You can have the mail marked Crash, Hold, Normal, or allow it to default. You can also have the echo mail not bundled but left as .MSG files in your mail directory for another program to work on. The actual rules and use of these options are left up to the Zmail documentation. However, they are completely supported by REC. Any character other than a number, color (:), slash (/), or period (.) is consider a special processing flag (or flavor code). You can up to 10 symbols on a single address, and they can be put on any address you need to. They also can be used with the FLAVOR batch command and the CROSSZONE configuration statement. Some default logic is imposed with these flavor commands. If you put any flavor on an echo for an echo node, it will stay there until you remove or change it. If it has no flavor when the echo node is added to the echo (via a message or batch), the flavor codes will be taken from the following places in this order: Batch Command Line Cross Zone Statement Echo Node or Echo Hub Statement If you wish to have all the echo mail for a certain echo node to have a certain flavor, just add that flavor to the address part of the Echo Node statement. Every time that echo node adds an echo, the flavor on the Echo Node statment will be used. This works for Echo Hubs as well as Echo Nodes. BATCH MODE There will be times that is will be easier and faster for you to submit an update to REC than to wait for the echo node to send mail. Batch mode allows you to do this with a simple text file and a command line parameter. Batch mode is optional for the Sysop. You may feel it faster and/or easier to make the change directly to the echo control file yourself. However, batch mode is reported in the log file which provides an audit trail. It can also be used to perform certain updates at a particular time such as nightly maintenance. Perhaps it single greatest advantage is in transferring an echo node from from echo hub to another. You could just setup an event to run REC with your special batch command file at a particular time, and let REC make the necessary changes while you are sleeping comfortably. To use batch mode, first you create a simple text file with any text editor. If you create the batch command file with the name BATCH.REC in the same directory as REC, it will automatically be run with the next run of REC. In this text file you just list the commands you want to execute with any needed parameters. The complete list of available commands is shown below: Add - This command allows you to add an echo node to an echo tag. ADD {tag},{echo node} Remove - This command allows you to remove and echo node from the distribution of an echo. The special tag for all tags can be used (see below). REMOVE {tag},{echo node} Create - This command allows you to create a new echo in the echo control file. To add echo nodes to this echo, you would need to use an "Add" command, which would have to be coded after this statement. CREATE {tag},{board,{feed} Drop - This command allows you to remove an entire echo from your echo control file. It is completly deleted from the file. DROP {tag} Flavor - This command allows you to set flavor to an echo for a particular echo node. Any flavor specified on the address directly will be ignored. The flavor must be placed after the echo node. To remove all flavor from the tag and echo node, use the special flavor of "*_NONE_*". The special for all tags can be used (see below). FLAVOR {tag},{echo node},{flavor} Board - This command allows you to change the board of an echo. You must specify the tag and the new board value. BOARD {tag},{board} Tag - This command allows you to change an echo tag. You must specify the current tag value, and the new value you wish to use. TAG {current tag},{new tag} Feed - This command allows you to change the feed for an echo. FEED {tag},{new feed} There is a special tag name that will cause the command to work on any echo tag. This can only be used on Remove and Flavor, for obvious reasons. The special tag value is "*_ALL_TAGS_*" and should be typed in all uppercase. Secondly, you execute REC with a command-line parm of /B followed immediately by the filename of the text file you just created. An example would be nice, and it follows below: REC /Bmyfile.txt In the above example, the file named "myfile.txt" will be read and processed as a batch file. If the filename cannot be found, an error message is displayed and logged. The batch file is processed first, and the commands are processed in the exact same way as if they came in from a net-mail message. NOTIFY MODE This is a quick and simple way to let your echo nodes what echos they are receiving. This helps to make sure that your echo node is getting only the echos desired, and all the echos desired. During this Notify Mode, REC will still process any batch command files and inbound messages addressed to REC. Most often, you would use this mode once a week in a maintenance mode. An example is shown below: REC /N This above example show the command line parm of "/N". This forces batch notify mode, and will send an Active Echo Report to every Echo Node listed in the configuration file, and only to those addresses. If desired, you can have REC create a sysop's status report during notify mode. This report is described next. STATUS REPORT The Status Report is can be generated by two different means. If the StatusReport configuration option is used, the report will generated when REC is run in Notify Mode (/N parameter, see previous section). It can also be generated by running REC is Report Mode (/R parameter. While running in report mode, REC will still process any batch command files or inbound messages. An example is shown below: REC /R The status report is sent as net-mail to the address shown in the first Address configuration statement, and address to the name listed in the Sysop configuration statement. This report is broken down into 4 major sections consisting of 3 summaries and a dead-end echo listing. The first summary is a summary of how many echos you have listed in your echo control file. A "Local Area" is not really an echo area, but is listed in the echo control file as required for an off-line message base reader such as QMX or RaQSeX. An "Imported Area" is an echo area that is imported into your local message base, essentially not a pass-through echo. A "Pass- Through Area" is an echo area that you get from one of your echo hubs and pass on, but do not import into your own message base. A "Dead-End Area" is an echo that area that your get from one of your echo hubs, don't import, and don't pass on. Usually you would want to stop these since they take up time and disk space for no gain. The second summary is an Echo Hub summary. It lists each of your echo hubs and how many echos are feed from that source. It ONLY reports on the echo hubs you have listed in your configuration file. The third summary is an Echo Node sumamry. It lists eacho of your echo nodes and how many echos they are receiving. It ONLY reports on the echo nodes you have listed in your configuration file. The last piece of the report does not always show up. It is the listing of each dead-end echo and its feed. This would allow you to issue cancel requests to the appropriate feed for the appropriate echos. You should realize that while the Echo Area Summary reports on every echo in your echo control file, the Echo Hub and Echo Node summaries do not. The total number of echos reported in the Echo Hub summary will equal the total number of echo areas ONLY if every one of your echo mail feeds are listed as an echo hub in your configuration file. POINT SYSTEMS Point Systems are also called Private Nets or Point Nets. In its simplest form, a point system is not much more than a private network of BBS's. It is a fact, however, that humans have become very good at making simple things complicated. The major difference is that point systems don't appear in the nationally distributed nodelist. The Boss Node of a point system is basically the door by which it dependent points talk to the rest of the world. All other BBS's just send the mail to the Boss Node, and the Boss node passes on the mail to the individual point systems. The point systems send all their mail to the Boss Node, which then passes that mail on the to the rest of BBS world. As far as echo mail is concerned, you are just passing it along like echo mail to any other BBS. Net mail takes a little more work, but there are a couple of different ways to handle that, all of which are beyond the scope of this documentation. The addressing of a point system of perhaps the most confusing part. There are 3 main ways to address a point system: private net, point reference, or the complete full address. Take my own system, for example. My FidoNet address is 1:104/435, and my private net (or point net) is 30527. I could address my fifth point (or private BBS) is any of these ways: 1:30527/5 (called private net) 1:104/435.5 (called a point reference) 1:104/435.30527/5 (the complete or "long hand" style) The second style, or point reference, is all that the rest of the BBS world would need to know to get a net-mail message to one of my points. Echo mail is passed down via the echo control file, just like it would be to any other BBS. Now for the specifics of how REC handles point systems. REC will (of course) accept any of these 3 formats of addressing a point system. The important point to remember is this: However you list the point system's address in the Echo Node definition, is how it will show up in the echo control file. Point systems will NOT be shown using the so called "short hand" for addressing. This is illustrated next. Assume that I receive the echo tag ABC from my local NEC, and I pass it off to two other systems (210 & 550) and two of own point systems ( 5 & 15). Here's what you would see in the echo control file if I used point referencing for my points: P ABC 1:104/1 210 435.5 435.15 550 If the second point listed (435.15) was only shown as "15", it would actually be sent to 104/15 instead of my point. If I used complete addressing, the same line would like this: P ABC 1:104/1 210 435.30527/5 435.30527/15 550 The same line would like this if I used private net addressing: P ABC 1:104/1 210 550 30527/5 15 As you may have noticed, the private net addressing looks just like address for net 104, except that the net number is 5 digits long instead of 3. It is your preference as to which method you want to use. What you should remember is this: If you use the PrivateNet addressing style, your mail processor will NOT strip the Private Net address from the seen-by and path lines. This may be against the policy of either your Net or FidoNet. Here is a very important tip to make your point systems easier to manage: Be consistent. That may sound meaningless, but if you are consistent then you have less confusion later on. It does require some small amount of extra thought up front, but it will be well worth it. All replies and notifies are sent directly to the point address, if the private net is known. If the private net is not know, than it will be sent out as regular net mail, and you will be expect to have some external program, such as REMAPPER to map it to the correct private net. If you use Private Net addressing (like 30527/5), you will have absolutely no problems. If you use complete addressing (like 1:104/435.30527/5), then you have fewer problems. If you use Point Reference, you will have to be careful about re-mapping both before and after REC is run, unless you put the private net number in the appropriate address statement. If I had an Address statement of 1:104/435.30527/0 and an Echo Node address of 1:104/435.5, than any replies and notifies would be sent to 30527/5 for that echo node ONLY!! Now that brings up a nice little feature of REC. If you specify a private net address on your Address statement, the private net will only be used when sending the message TO one your points. See the example below: Address 1:104/435.30527/0 EchoNode 104/210,,Test1,100,First_Joker EchoNode 435.5,,Test2,100,Second_Joker All notifies and replies will be sent to First Joker on 104/210, or to Second Joker on 30527/5. This type of setup gives you maximum flexibility to do this in which ever manner you want. Just be consistent so you don't start to confuse yourself. If you want a recommendation from the author (ie. me!), I suggest that you use Point Reference addressing. This way the your point appears no different than your own system to the outside world. Also, REC will do the reply and notify address mapping for you. Below is my recommendation in an example: Address 1:104/435.30527/0 EchoNode 104/210,,Test1,100,First_Joker EchoNode 435.5,,Test2,100,Second_Joker ERRORS/MESSAGE PROCESSING REC can return many different messages, and not all of them are errors. In this section, I will list all of the error conditions, and where they are reported. Everyone of these errors/messages will be sent to the log file and the display screen. I will not be covering the configuration errors, since they are well detailed by the program error message if any should be encountered. First I will cover those messages that can be produced by a message sent to REC from an echo node: 'Not found or processed': The command was not processed by REC due to an error condition. You should not see this message, but it was added to cover all possible logic flaws in the program where a message command might be skipped. 'Added': The echo was activated for the echo node. 'Already active': 'The echo was already active for that that echo node. 'Insufficient security': The echo node lacked sufficient security level to access that echo. 'Locked out': The echo node has been locked out of that echo via the Lockout statement in the configuration. 'Zone-crossing restricted': That echo node is not allowed this echo since the echo would be crossing a zone. If a CrossZone statement was involved, it was because the security of the echo node was less than the minimum specified on the CrossZone statement. 'Forwarded': The echo was activated for the echo node and forwarded to the echo hub. 'Not active': The echo node was not receiving the specified echo so it could not be removed. 'Removed': The echo node was removed from the echo. 'Invalid report code': A report was requested, but the report code was not one recognized by REC. 'Active echo report generated': This report was created. 'Available echo report generated': This report was created. 'Not found or forwarded': The echo did not exist and could not be forwarded. Listed next are the error messages that can be generated by a batch command: 'Not Processed': This is the same as the one above. 'Processed': The command was processed correclty. 'Tag not found': The echo requested was not found. 'Node not found': The node request was not found. 'Tag already exists': A tag could not be created because that tag was already being used by an existing echo. 'Node already active': The node was already active for the echo. 'Invalid Command': Either the command was unknown or one or more of the parameters were missing. BONUS UTILITIES As a free bonus, I have included a few simple little utility programs that I find useful on my system. The command syntax can by found by simply executing the program without any command line parameters. I will give the syntax here as well, along with a short description of what the program does. AreaList - This program takes an echo control file and produces a 3 column, alphabetically sorted, listing of all echo tags found. No consideration is given for separating by zones. AREALIST {echo control file} {list filename} AreaRpt - This program will produce a report from your echo control file. The report is a listing of every system found, and which echos that system is receiving from you. Is is sorted alphabetically in a 3-column format. AREARPT {echo control file} {report name} ReadMsg - This is a quick and dirty public domain utility that basically displays the formatted contents of a .MSG file. READMSG {msg filename} EchosOut - This program is designed to be put right in the REC directory. It keeps track of how much echo mail you send out. You should run it immediately after you process any received echo mail, and after you process any echo mail generated on your system. It reads the outbound directory given, updates a small tracking file called ECHOSOUT.TRK, and writes out a sorted report. The tracking file will be created/update in the current directory. This report lists for each system found the system address (with out zone) and the total daily volume in Kybtes for the last 7 days. A Zone total and Run Total are also generated. You should note a few things. Always run the program from the same directory, so it can always use the same tracking file. To reset the report, just delete the tracking file. Make sure the address on the command line parm is your PRIMARY address but do NOT give the zone. Only specify the outbound directory for your primary zone, meaning without an extension. The program will automatically check for the other directories. The program only takes a few seconds to run, and it real useful watching how much echo mail your system in handling. ECHOSOUT {outbound directory} {net/node} {report file} ECHOSOUT m:\out 104/435 volume.txt CONCLUSION Well, that's about all I have to say about REC and the bonus utilities. If you have any questions, feel free to contact me via net-mail to 1:104/435@FidoNet or 200:5000/211@MetroNet. Send the message to Dan Fitch, or to Sysop. There is a support echo on the FidoNet backbone. The echo tag is called REC_SYSOP, and I encourage you use this echo. If you cannot get access to that echo, feel free to contact me via the ZZYZX software support echo. I have Claude Warren's (the moderator) permission to use the echo for that purpose. I have several plans in mind for Version 2.0 of REC. Some of these include a full-screen on-line door program to allow you to directly examine, search, and update the echo control file while on-line while maintaining an acurate log of what you did. The limits imposed by using static memory will be further replaced with dynamic memory allocation, which will make REC faster and more efficient. These will include the Address, EchoHub, and EchoNode configuration statements. Best of luck in you BBSing, and my thanks for using this software. Later! Dan Fitch Author of Remote Echo Control (REC) Sysop of The Rec Room 1:104/435@FidoNet 200:5000/211@MetroNet Denver, Colorado revised April 20, 1991.